Ohh I did not expect to see this problem in practice, having noticed it only while handling platforms manually and not through the nixpkgs entrypoint, for testing.
I'd discussed a plan to mitigate the problem with @Ericson2314. It's still more of a workaround than a solution, I have to admit.

1. add a platform equality function to lib.systems
2. use it in all places where nixpkgs consumers system/platform parameters, so they can be turned into equal platforms, along these lines

# *Platform omitted for brevity
args@{ host, build }:
let inherit (
  # actually this part could be turned into a function
  if systems.equals args.host args.build
  then { inherit (args) host; build = host; }
  else { inherit (args) host build; }
  ) host build;
in
  # use host and build as usual

That way we can keep using regular equality on these types.
What's ugly is that its a bad habit in case you ever have to compare systems between distinct nixpkgs invocations. There's no workaround for that, except to use lib.systems.equals.

I think the real solution is to either
a. make equality break, so that nobody can use it by accident, or
b. remove all functions and put them in lib.systems instead.

But until we decide that, we may as well fix it for 95% of cases by explicitly making the values identical where it matters most.

The issue happens simply when just importing nixpkgs with localSystem.system = "x86_64-linux" or localSystem = "x86_64-linux". Whether or not I specify crossSystem = localSystem makes no difference; I have tried it both ways, traced it through default.nix and top-level/impure.nix and have determined that this would be the default regardless. I don't know why nobody else can confirm this, as the broken example given in the issue description is not as simple as my use.

Perhaps we could fix 100% of the problem by fixing function comparison in Nix?

  intrepid = inputs.nixpkgs.lib.nixosSystem {
    modules = with tree.hosts.intrepid; [
      bootloader
      filesystems
      plymouth
      configuration
      packages
      powerplan
      touchpad
      greeter
      # gamemode
      gaming
      pia-openvpn
    ];
    pkgs = import inputs.nixpkgs-unstable {
      overlays = [
        # flake packages
        self.overlays.default
        # override packages with an unfree license
        self.overlays.allowUnfree
        # other packages
        inputs.slight.overlays.default
        inputs.ragenix.overlays.default
      ];
      localSystem = "x86_64-linux";
      crossSystem = "x86_64-linux";
      config.allowUnfree = true;
    };
    specialArgs = {
      enableUnstableZfs = false;
    };
  };

I will see the following error:

error:
       … while calling the 'seq' builtin

         at /nix/store/3lv5x5bn3bvy0xmd35ds3dsmvk23591w-source/lib/modules.nix:326:18:

          325|         options = checked options;
          326|         config = checked (removeAttrs config [ "_module" ]);
             |                  ^
          327|         _module = checked (config._module);

       … while evaluating a branch condition

         at /nix/store/3lv5x5bn3bvy0xmd35ds3dsmvk23591w-source/lib/modules.nix:267:9:

          266|       checkUnmatched =
          267|         if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [] then
             |         ^
          268|           let

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: Neither nixpkgs.hostPlatform nor the legacy option nixpkgs.system has been set.
       You can set nixpkgs.hostPlatform in hardware-configuration.nix by re-running
       a recent version of nixos-generate-config.
       The option nixpkgs.system is still fully supported for NixOS 22.05 interoperability,
       but will be deprecated in the future, so we recommend to set nixpkgs.hostPlatform.

To resolve this temporarily I attempted to add { config.nixpkgs.hostPlatform = hostPlatform; } as a module, but this causes other problems.

Perhaps we could fix 100% of the problem by fixing function comparison in Nix?

It's fundamentally unfixable because of undecidability. We should make it throw, but that's a big breaking change.
I suppose we could make equality overridable. That would still take a while to be available in Nixpkgs, fwiw.

error: Neither nixpkgs.hostPlatform nor the legacy option nixpkgs.system has been set.

That shouldn't happen. You've specified pkgs manually, so the options in misc/nixpkgs.nix should be ignored. However, it is set through _module.args.pkgs and not through nixpkgs.pkgs so misc/nixpkgs.nix doesn't know that it should disable its assertions.

I've added a safe alternative read-only nixpkgs module as part of this.

• Fast nixos test eval #230523

Maybe that should be loaded by nixosSystem/eval-config.nix when pkgs is set, or maybe its behavior should be integrated into the standard module. That's a quite a challenge, not to break existing configs while making subtle changes there, but if we're willing to break the pkgs argument behavior anyway...

For now you could fix your example by setting the nixpkgs.pkgs option instead of the nixosSystem pkgs argument.

For now you could fix your example by setting the nixpkgs.pkgs option instead of the nixosSystem pkgs argument.

This seems to me missing the binary cache, I am rebuilding too many things. Tried both localSystem.system = "x86_64-linux" and localSystem = "x86_64-linux".

This is not a problem when I pass pkgs to nixosSystem and manually set the option config.nixpkgs.hostPlatform.

I have cherry-picked the commits from both pull requests, and add a module {config.nixpkgs.pkgs = ...;} but get infinite recursion. Now when I try to add --show-trace to the command, I see

error: cached failure of attribute 'nixosConfigurations.intrepid.config'

This is happening a lot now and it is very annoying. Sometimes I want to see an error message multiple times. How do I prevent this "cache" error from happening? What does it mean? Why am I seeing it more?

Maybe you know about this well enough to save me the trouble of recovering the full trace (this time).

error:
       … while calling the 'seq' builtin

         at /nix/store/vj42zj0563qkm9ga6473a8k8il55v38h-source/lib/modules.nix:326:18:

          325|         options = checked options;
          326|         config = checked (removeAttrs config [ "_module" ]);
             |                  ^
          327|         _module = checked (config._module);

       … while evaluating a branch condition

         at /nix/store/vj42zj0563qkm9ga6473a8k8il55v38h-source/lib/modules.nix:267:9:

          266|       checkUnmatched =
          267|         if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [] then
             |         ^
          268|           let

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: infinite recursion encountered

       at /nix/store/vj42zj0563qkm9ga6473a8k8il55v38h-source/lib/modules.nix:512:28:

          511|         builtins.addErrorContext (context name)
          512|           (args.${name} or config._module.args.${name})
             |                            ^
          513|       ) (lib.functionArgs f);

Is it possible that the following lines in impure.nix are responsible for the original problem?
My guess is that the values localSystem and crossSystem are not the same if both are provided, as some other value is used via the confusing default logic.

This is the top of the attrset bound to args:

{ # We put legacy `system` into `localSystem`, if `localSystem` was not passed.
  # If neither is passed, assume we are building packages on the current
  # (build, in GNU Autotools parlance) platform.
  localSystem ? { system = args.system or builtins.currentSystem; }

# These are needed only because nix's `--arg` command-line logic doesn't work
# with unnamed parameters allowed by ...
, system ? localSystem.system
, crossSystem ? localSystem

Perhaps the issue that you "did not expect to see ... in practice" is caused by this confusing evaluation flow.

My tests show otherwise, but I feel as if I am still missing something.

nix-repl> test = args @ { localSystem ? { system = args.system; }, system ? localSystem.system, crossSystem ? localSystem }: { inherit localSystem crossSystem; }

nix-repl> :p test { system = "x86_64-linux"; }
{ crossSystem = { system = "x86_64-linux"; }; localSystem = «repeated»; }

nix-repl> :p test { localSystem = "x86_64-linux"; }
{ crossSystem = "x86_64-linux"; localSystem = "x86_64-linux"; }

nix-repl> :p test { localSystem.system = "x86_64-linux"; }
{ crossSystem = { system = "x86_64-linux"; }; localSystem = «repeated»; }

# is this the problem?
nix-repl> :p test { localSystem = "x86_64-linux"; crossSystem = "x86_64-linux"; }
{ crossSystem = "x86_64-linux"; localSystem = "x86_64-linux"; }

nix-repl> :p test { localSystem.system = "x86_64-linux"; crossSystem.system = "x86_64-linux"; }
{ crossSystem = { system = "x86_64-linux"; }; localSystem = { system = "x86_64-linux"; }; }

I understand that you both have already looked into this and are aware of this. I guess what I'm still stuck on is this: If they are the same value here, whether string or attrset, default or provided; why does the comparison differ?

The following two attrsets can begotten from either the default crossSystem value or if they are assigned to both be the same when importing nixpkgs.

{ crossSystem = { system = "x86_64-linux"; }; localSystem = «repeated»; }
{ crossSystem = "x86_64-linux"; localSystem = "x86_64-linux"; }

So why does the comparison see them as different? Because of the lack of the usage of lib.systems.equals? Okay, then furthermore, why does it work when the same value is achieved through crossSystem ? localSystem but not if it were manually set?

I'm still trying to wrap my head around this. As far as I can tell, through days of playing with it, the file in which the comparison is performed (before lib.systems.elaborate) should get the same values whether or not crossSystem was manually set or not.

error: cached failure of attribute 'nixosConfigurations.intrepid.config'

Which nix version, and which command is that?
That error should only ever be visible in commands that deal with large quantities of attributes, so this particular error seems like a Nix bug.
Related:

• Nix flakes should not cache evaluation errors nix#3872

Which nix version, and which command is that?

Both nix build and nixos-rebuild produce the same message if invoked twice, the first time resulting in an error code and trace.

Nix version is 2.15.1.

I think the real solution is to either
a. make equality break, so that nobody can use it by accident, or
b. remove all functions and put them in lib.systems instead.

I think these are the only two reasonable solutions.

Does anybody object strongly to (b)?

Edit: #238331

#254763 which seems to make this unnecessary, was merged.